One of the star controls that PCI DSS version 4.0 incorporated was protection against e-skimming attacks through requirements 6.4.3 and 11.6.1. This control was the response of the PCI SSC to the massification of this type of attack in previous years. This article will describe the different technical alternatives to implement it.
Introduction
In June 2008, Ticketmaster suffered a security incident It affected nearly 40,000 customers including names, addresses, emails, phone numbers and payment details, including card details. That incident had its origin in a service provider of chatbot (Inbenta Technologies) that had been previously committed. Because the components of this service chatbot uploaded camouflaged on card data capture pages when payments were made, criminals were able to capture and exfiltrate this sensitive information undetected for several months.
Similar attacks were identified on the e-commerce pages of British Airways, Hanna Anderson, Snowflake and many other websites that mostly ran vulnerable versions of Magento.
Copy of the 22 lines of code that were injected into the British Airways website to exfiltrate confidential information
All of these attacks had a similar pattern of operation:
- Attack on e-commerce websites with massive traffic belonging to well-known companies.
- Using automation to optimize infection times at vulnerable sites.
- Use of code injection techniques and obfuscation techniques to create false payment forms or modify the logic in the capture and sending of data in existing forms, where the normal operation of the affected site is not compromised, in order to guarantee persistence to the offender.
- Activation of reinfection tasks so as not to lose control of the compromised sites.
- Attacks on service providers and external components (such as libraries, JavaScript code, etc.) to compromise them and subsequently load the compromised components onto their customers' websites (supply chain attacks).
- The focus of the attacks was on payment card data.
Due to the similarity in its operation with the attacks of skimming physical (where criminals manipulate physical card data-reading interfaces of electronic teller machines and payment terminals to read and copy information from a card's magnetic stripe or chip), these attacks were termed e-skimming, digital skimming, web skimming or formjacking, client-side attacks (client-side attacks) where attackers inject malicious code into e-commerce websites to compromise sensitive information (typically card data) entered by users on payment pages (checkout) or other online forms without the affected user being aware of the attack.
Cybercriminals using these techniques (active since 2014) were listed under the brand name “MageCart”, as many of their attacks targeted vulnerable e-commerce platforms that were running Magento.
In order to protect yourself from such attacks, it is recommended to implement the following measures:
- Identify all active components (JavaScript and ActiveX) running on the website.
- Establish trusting relationships with active component suppliers.
- As far as possible, run active component instances locally instead of invoking them remotely.
- Implement headers HTTP Content-Security-Policy (CSP), which offer an additional layer of protection against attacks from cross-site scripting (XSS), clickjacking and other code injection attacks.
- Keep up-to-date the base software and all libraries and components that are part of an e-commerce site.
PCI DSS approach: Requirements 6.4.3 and 11.6.1
PCI DSS version 4.0 incorporated two requirements for e-skimming attack protection:
Requirement 6.4.3:
- Implement a method to confirm that each script loaded and executed in the client's browser is authorized.
- Ensure the integrity of each script.
- Maintain an inventory of all scripts along with their written usage justification, whether for technical or business reasons.
This requirement applies to all scripts loaded from the entity environment and to scripts loaded from thirds and quarters.
Requirement 11.6.1:
Deploy a change detection and tampering mechanism to:
- Alert staff if unauthorised modifications of
- Security Headers (HTTP headers) with security impact
- Content of scripts received by the user's browser during the payment process
- Such mechanisms must be configured to evaluate HTTP headers and payment pages.
- These functions should be executed on a weekly or periodic basis (the institution can define the frequency through a targeted risk analysis).
These controls are mandatory from 1 April 2025.
Implementation options
Although the implementation of a particular solution is not required, in technical terms these controls can be implemented through four (4) different approaches:
Option 2: Agentless web monitoring
These types of solutions, also called agentless (agentless) or synthetic users (bots) typically emulate a user's web browser interactions and analyze all content that has been provided from a particular web page.
| Advantages | Disadvantages |
|---|---|
| Does not require any changes to the website to monitor | Its execution is usually programmed, in such a way that time windows can be presented in which malicious content may not be detected. |
| You can monitor the entire operational flow of a session, as if it were a real user | Its execution is slower, since it consumes more resources |
| Its way of working is detective, it has no way of executing corrective actions against the detection of malicious behavior. |
Examples of solutions that implement this approach:
- RapidSpike: https://www.rapidspike.com/magecart-attack-detection/
- Reflectiz: https://www.reflectiz.com (although it also implements proxy functionalities, as will be seen later).
Option 3: Web monitoring with agent
In agent monitoring, a reliable component (agent) is installed/invoked on the web page of the server to be monitored. This agent (which will be loaded in the user's browser) will be responsible for monitoring in real time any changes that are made to the loaded components of the monitored pages and analyzing their behavior, being able to act in a detective way against unauthorized actions (client-side monitoring).
| Advantages | Disadvantages |
|---|---|
| Deploying agents is simple, performed through JavaScript invocations. | Integration usually involves the deployment of additional lines of code on the websites to be protected. |
| Depending on the solution, HTTP headers can also be monitored. | Depending on the solution, the agent will only be able to report the results of the monitoring, without the ability to "block" malicious content. |
| Monitors the behavior of each script during its execution. | These types of solutions usually have many false positives and require manual tuning. |
Examples of solutions that implement this approach:
- JScrambler: https://jscrambler.com
- SourceDefense: https://sourcedefense.com/
- Feroot: https://www.feroot.com
- Human Security: https://www.humansecurity.com
Option 4: Use of proxies
Unlike the previous solutions, proxies-based solutions usually intercept traffic between the web server and the user's browser, reviewing the transmitted content and detecting any type of change BEFORE the content is distributed to the end user. Some of these solutions integrate with Content Delivery Network (CDN) platforms in such a way that you can have full control over traffic flows, being able to block malicious content BEFORE it is distributed to the end customer.
| Advantages | Disadvantages |
|---|---|
| Does not require installation or modifications to the web server to protect | These types of solutions are usually based on CSP/SRI policies, so it is necessary that the administrator of the solution knows the operation of these specifications. |
| Integrates with other tools such as WAF modules, antimalware detection, cache solutions, etc. | Needs tuning tasks. |
| If your deployment is linked to a CDN, an extra layer of availability is added. | It does not protect interfaces or sections of the website that are not behind the proxy service. |
Examples of solutions that implement this approach:
- Akamai Client-Side Protection & Compliance: https://www.akamai.com/es/products/client-side-protection-compliance
- Cloudflare PayShield: https://www.cloudflare.com/en-gb/application-services/products/page-shield/
- Imperva Client-Side Protection: https://www.imperva.com/products/client-side-protection-csp/
- c/side: https://cside.dev/
Conclusion
With the attacks of e-skimming/formjacking On the upside, it is imperative that e-commerce sites that capture card data deploy detective and reactive controls geared towards detecting malicious active code (primarily JavaScript) that can be loaded into the end-user's browser. These controls must validate the integrity of authorized HTTP scripts and headers and deny/report any suspicious behavior.
Depending on the complexity of the e-commerce websites to be protected, the amount of traffic to be analyzed, the periodicity in which these validations must be carried out and the additional load on the performance of the website, entities can choose between several implementation options to achieve compliance with PCI DSS v4.0 controls 6.4.3 and 11.6.1, which take effect from April 1, 2025.
EN 
ES